How Do So ware Developers Identify Design Problems?

When a software design decision has a negative impact on one or more quality attributes, we call it a design problem. For example, the Fat Interface problem indicates that an interface exposes non-cohesive services. Thus, clients and implementations of this interface may have to handle with services that they are not interested. A design problem such as this hampers the extensibility and maintainability of a software system. As illustrated by the example, a single design problem often a ects several elements in the program. Despite its harmfulness, it is di cult to identify a design problem in a system. It is even more challenging to identify design problems when the source code is the only available artifact. In particular, no study has observed what strategy(ies) developers use in practice to identify design problems when the design documentation is unavailable. In order to address this gap, we conducted a qualitative analysis on how developers identify design problems in two di erent scenarios: when they are either familiar (Scenario 1) or unfamiliar (Scenario 2) with the analyzed systems. Developers familiar with the systems applied a diverse set of strategies during the identi cation of each design problem. Some strategies were frequently used to locate code elements for analysis, and other strategies were frequently used to con rm design problems in these elements. Developers unfamiliar with the systems relied only on the use of code smells along the task. Despite some di erences among the subjects from both scenarios, we noticed that developers often search for multiple indicators during the identi cation of each design problem.